Завдання планування та ефективного управління підприємствами - одна з основних областей застосування інформаційних технологій, які є базою автоматизованих систем управління (АСУ).
АСУ може бути представлена у вигляді сукупності автоматизованих систем взаємодіючих рівнів (рис. 1.1), умовно названих «управління підприємством» (рівень ERP, MRP), «управління виробництвом» (рівень MES), і «управління технологічними процесами і устаткуванням» (рівень DCS).
Рис.1 Блок - схема автоматизованої системи управління
Рівень ERP реалізується автоматизованими системами управління підприємством (АСУП), рівень DCS - автоматизованими системами управління технологічними процесами (АСУ ТП), а найважливішою функцією рівня MES є поєднання між АСУП і АСУ ТП.
Перш ніж відновити історію створення та впровадження автоматизованих систем управління підприємством (АСУП) в Україні (колишньому СРСР), необхідно уточнити, про що йде мова з точки зору сучасних понять про інформаційні технології. Колись тиражований термін АСУП зараз майже не використовують. Справа тут в тому, що зміст поняття «автоматизована система управління», що передбачала присутність людини як ланки системи управління, було втрачено. Багаторазове згадка поняття АСУП призвело до того, що перестали помічати що міститься в цьому протиріччі. Насправді саме функції управління підприємством ніколи не були реалізовані в АСУП, вони лише надавали інформацію особам, які приймали рішення по управлінню підприємством, в той же час перебували поза системою.
Роботи зі створення АСУП в рамках напрямку, що називався «економічної кібернетикою», були розпочаті за ініціативою академіка В.М. Глушкова в Інституті кібернетики АН СРСР в 1963 - 1964 рр.
Першою в СРСР системою для підприємств з крупносерійним характером виробництва була АСУП «Львів», впроваджена на Львівському телевізійному заводі «Електрон».
Рішення завдання, поставленого В.М. Глушковим, - створити не індивідуальну для даного підприємства, а типову систему, призвело до методів побудови прикладних програм, що використовують параметричну настройку на особливості конкретного підприємства при прив'язці, налагодження та впровадження типової системи. Ці методи максимального використання параметрів, а не числових значень при побудові прикладних програм, стали згодом широко поширеними і використовуються досі в корпоративних інформаційних системах планування ресурсів підприємства (ERP).
Глушковим В.М. було запроваджено поняття спеціалізованої операційної системи, призначеної для систем з регулярним потоком завдань. Універсальні операційні системи для вирішення випадкових потоків завдань в пакетному режимі в обчислювальних центрах, наприклад OS / 360 фірми IBM для сімейства мікропроцесорів 360, не дозволяли використовувати переваги, які представляв регулярний потік завдань в АСУП. Тому для програмного забезпечення АСУП на базі вітчизняних ЕОМ другого покоління серій «Мінськ» і «Урал» були розроблені програмні засоби управління розкладом завдань, попередньою підготовкою інформації і мультипрограмними режимами виконання прикладних програм. Хоча до штатних операційних систем ЕОМ «Мінськ» і «Урал» такі рішення не були доведені. В кінці 1960-х - початку 1970-х рр. після завершення робіт по АСУП «Львів» під керівництвом В.М. Глушкова була створена типова АСУП «Кунцево», впроваджена на Кунцевському радіозаводі. Створення великих АСУП «зажадало» використання і розвитку методів оптимізації. Роботи в цій області проводилися в Інституті кібернетики АН УРСР під керівництвом В.С.Михалевича. У 1960 - 1962 рр. була запропонована загальна алгоритмічна схема послідовного аналізу варіантів, що включала в себе, як окремий випадок, обчислювальні методи динамічного програмування. Ця схема була розвинена разом з методами математичного моделювання для вирішення завдань упорядкування, зокрема в теорії розкладів і календарного планування. Ці результати послужили математичною основою АСУВ «Львів» і «Кунцево».
Новий етап у розвитку АСУП припав на другу половину 1970-х рр. і 1980-і рр. Це були комплексні системи, в яких інтегрувалися завдання автоматизованого проектування нових виробів (САПР), технологічної підготовки виробництва, автоматизації випробувань готових виробів і автоматизації організаційні управління підприємством. Технічну базу нового покоління АСУП складали, як правило, моделі ЄС ЕОМ, СМ ЕОМ.
До недавнього часу автоматизація підприємства велася за трьома окремим та незалежним один від одного напрямках: системи автоматизації управлінської та фінансово-господарської діяльності (АСУП), системи автоматизованого проектування (САПР) і системи автоматизації технологічних і виробничих процесів (АСУ ТП). Дані системи проектувалися і створювалися виходячи з вимог різних підрозділів підприємств, вони не підпорядковувалися єдиним цілям і задачам, були погано пов'язані фізично та інформаційно, кожна система будувалася за своїми внутрішніми законами. Великим недоліком було ще те, що системи базувалися на різних апаратних, програмних і інформаційних стандартах.
Все перераховане вище не дозволяло керівникам підприємств побудувати єдину автоматизовану систему управління підприємством. Керівники підприємств постали перед важким вибором: з чого починати автоматизацію - з АСУП, САПР або АСУ ТП, на які стандарти орієнтуватися? Визначальною тенденцією в розвитку єдиної системи управління підприємством стало логічне та інформаційне взаємопроникненя різних рівнів: бізнес-рівня (АСУП), рівня проектування (САПР) і виробничо-технологічного рівня (АСУ ТП). Завдяки взаємопроникненню цих систем, підприємство стає єдиним організмом, який функціонує в єдиному інформаційному просторі.
Тільки тоді, коли підприємство стає єдиним цілим, можливо ефективне управління фінансово-господарською та виробничою діяльністю підприємства. Крім того, йде активне зближення стандартів і спрощується завдання сумісності різних апаратних і програмних засобів. Це дозволяє уникнути додаткових витрат при об'єднанні в одну систему обладнання різних виробників. В даний час стрімко розвиваються Інтернет-технології, які стають невід'ємною частиною всієї автоматизованої системи підприємства. Все вищесказане дозволяє кожному учаснику виробничого процесу самостійно, без фахівців-посередників, за допомогою спеціально розробленого інтерфейсу запитувати і приймати необхідну інформацію, здійснювати налаштування різних режимів свого інформаційного обслуговування, що сприяє підвищенню ефективності виробництва, але при цьому виникає проблема інформаційної безпеки роботи обчислювальної системи, цілісності даних, що зберігаються. Особливо актуально вирішення цих питань в корпоративних системах, де взаємодіють між собою величезна кількість користувачів. Бізнес, який стає глобальним і розподіленим, вимагає загального простору для роботи з інформацією. Через Інтернет забезпечується доступ до корпоративних даних, в тому числі і до життєво важливої інформації підприємств. Якщо державні організації, військові або дипломатичні відомства працюють з закритими мережами, то у комерційних організацій такої можливості немає: це невигідно, незручно і недоцільно.
В даний час замість поняття АСУП використовується більш точне поняття - корпоративні інформаційних системи (КІС). Під ними розуміють системи, в яких функціонально об'єднуються системи для вирішення завдань автоматизації обліку та управління виробництвом, фінансами, постачанням і збутом, кадрами і інформаційними ресурсами. Технічну базу сучасних КІС, що використовують переважно розподілену архітектуру клієнт-сервер, складають сервери і робочі місця користувачів, об'єднані локальний мережами. Перш ніж перейти до розгляду наступних розділів посібника, введемо ключове поняття «інформаційних система».
1.1. Інформаційна система
Інформаційна система (ІС) - це вся інфраструктура підприємства (організації), задіяна в процесі управління всіма інформаційно-документальними потоками, що включає в себе наступні основні елементи:
• інформаційна модель, що представляє собою сукупність правил і алгоритмів функціонування ІС. Інформаційна модель включає в себе всі форми документів, структуру довідників і даних і т.д .
• регламент розвитку інформаційної моделі та правил внесення в неї змін;
• програмний комплекс, конфігурація якого відповідає вимогам інформаційної моделі;
• апаратно-технічна база (комп'ютери, периферійні пристрої, канали зв'язку, системне ПО, СУБД).
Інформаційну систему можна представити у вигляді моделі, що складається з кілька взаємодіючих рівнів ієрархії (рис. 1.2). В основі моделі лежить шар різних типів комп'ютерів, що є засобами зберігання і оброблення даних. Комп'ютери формують апаратну платформу інформаційної системи. Транспортна система складається з активних і пасивних мережевих пристроїв, що об'єднують комп'ютери в локальні і глобальні мережі і забезпечують обмін даними. Активними мережевими пристроями є мережеві адаптери і модеми комп'ютерів, концентратори, комутатори, маршрутизатори та інші подібні пристрої. Середовище передачі даних і елементи кабельної мережі складають пасивну частину транспортної системи. Шар мережевих операційних систем забезпечує виконання додатків користувачів і за допомогою транспортної системи організовує доступ до ресурсів інших комп'ютерів і надає свої ресурси в загальне користування. Операційні системи комп'ютерів визначають програмну платформу інформаційної системи. Ряд активних мережевих пристроїв, таких як комутатори і маршрутизатори, як правило, працюють під управлінням власних операційних систем, так званих операційними системами між мережевої взаємодії.
Рис. 1.2 Ієрархічна модель інформаційної системи
Над шаром операційних систем працюють шари різних додатків. Системні сервіси служать для обробки і перетворення інформації, отриманої від систем управління базами даних (СУБД) та інших ресурсів, у вигляд зручний для сприйняття кінцевим користувачем або прикладною програмою. СУБД іноді виділяються в окремий шар. Цим підкреслюється їх висока значимість як засобу зберігання в упорядкованому вигляді даних і виконання базових операцій пошуку і вилучення потрібної інформації.
Верхній шар інформаційної системи складають додатки предметної області, специфічні для конкретного підприємства (організації) або певного типу підприємства. Це можуть бути програмні системи автоматизації бухгалтерського обліку, проектування, управління виробництвом, агрегатами, технологічними процесами та інші.
Інформаційна система підприємства створюється для роботи прикладних програм. Саме ці програми забезпечують співробітників необхідною інформацією для прийняття рішень і автоматизують діяльність різних служб. Тому при проектуванні інформаційної системи спочатку визначаються вимог до цих програм, а вже потім - які системні сервіси, бази даних, операційні системи, мережеві засоби, комп'ютери і сервери необхідні для їх ефективного функціонування.
З точки зору програмних технологій інформаційна система - це не один, і навіть не кілька програмних комплексів. Можна побудувати структурну модель інформаційної системи, виділивши її основні компоненти, які містять програмні модулі певного класу рисунок 1.3.
Рис. 1.3 Структурна модель інформаційної моделі
Самим нижнім рівнем інформаційної системи є сховище, в якому міститься вся інтелектуальна власність підприємства. Це можуть бути документи, довідники, структурні таблиці, ділові правила, опис процесів. Прямого доступу до сховища бути не повинно, як для користувачів, так і для різних систем підприємства. Прямий доступ має лише система управління знаннями, яка служить свого роду шлюзом для інших систем і формує інформаційне оточення підприємства. Система управління знаннями об'єднує ідеї, знання, зміст документів і ділові правила, автоматизуючи процеси, що базуються на знаннях, як всередині підприємства, так і між різними організаціями. Для цього потрібен шлюз, що дозволяє проводити обмін даними з зовнішніми системами. Це необхідна умова, так як сучасні процеси спрямовані на об'єднання підприємств в корпорації і очевидно, що передача знань дуже важлива. Наприклад, системи планування ресурсів підприємства (ERP - Enterprise Resource Planning) не можуть працювати незалежно - процеси, пов'язані з управлінням фінансами, складами, людськими ресурсами, використовують вже накопичені знання і додають нові.
Також важливо виділити клас систем аналізу і прийняття рішень (DSS-decision support system), без якого життєвий цикл інформації не буде завершено. У сучасних підприємствах інтелектуальний аналіз даних стає все більш важливим завданням. Пов'язано це з необхідністю аналітичної обробки більших обсягів інформації, що накопичилася в сховищах. Такі системи допомагають знайти нові знання, виявити недоліки і слабкі місця інформаційної системи, оцінити ефективність тих чи інших процесів, встановити нові інформаційні взаємозв'язку.
Часто кажуть, що такий клас систем має працювати безпосередньо зі сховищем, оскільки обробленню підлягають дані, що містяться в ньому. Теоретично це вірно, але на практиці таке неможливо – будь-які зміни у вмісті сховища, процесах, правилах і взаємозв'язках можуть і повинні здійснюватися через систему управління знаннями. Тоді DSS-систем не доведеться «замислюватися» над тим, в якому форматі зберігати дані, і головне, що будь-яка зміна інформації буде негайно впливати на взаємозв’язок і процеси, в яких вона бере участь.
Сформулюємо мінімальний перелік вимог до КІС. Функціональна повнота системи. Враховуючи, що методологічні підходи всіх розробників програмного забезпечення до структуризації предметної області та назвою формованих додатків розрізняються, загальною характеристикою функціональної повноти корпоративної інформаційної системи є кількість одноразово врахованих параметрів діяльності підприємства. Вважається, що для КІС значення цих параметрів повинно бути приблизно таким:
• кількість врахованих параметрів 2 - 10 тисяч;
• кількість таблиць баз даних 800 - 3000.
КІС повинна забезпечувати не тільки формування звітів, а й ведення обліку за міжнародним стандартам (ISA і GAAP).
Обов'язковою умовою є локалізація інформаційної системи: облік національного законодавства та системи розрахунків; інтерфейс і система допомоги на національній мові.
Система повинна забезпечувати розмежування доступу до даних і функцій, попереджати спроби несанкціонованого доступу до інформації.
КІС - система постійно розвивається, як в силу впливу зовнішніх факторів (наприклад, постійних змін в законодавстві), так із-за зміни бізнес-функцій підприємства, тому необхідно наявність інструментальних засобів адаптації та супроводу системи:
• управління структурою і функціями бізнес-процесів;
• зміна інформаційного простору (редагування БД, модифікація структури, полів таблиць, зв'язків, індексів і т.п.);
• модифікація інтерфейсів введення, перегляду і коригування інформації;
• зміна організаційного і функціонального наповнення робочого місця користувача;
• генерація довільних звітів, складних господарських операцій і форм.
Враховуючи важливість збережених у системі даних , слід забезпечити : авторизацію інформації, реєстрацію часу введення і модифікації даних, ведення протоколу вилучень даних,
Як правило, більшість підприємств, для яких розробляються КІС, вже мають встановлені автоматизовані системи: АСУ ТП, САПР і т. п. Важливо забезпечити обмін даними між КІС і іншими програмними продуктами, що функціонують на підприємстві.
Для користувачів КІС велике значення має можливість консолідації інформації: на рівні підприємств – для об'єднання інформації філій, дочірніх компаній, підприємств, що входять в холдинг тощо; на рівні окремих завдань, на рівні часових періодів – для виконання аналізу зміни тих чи інших показників за період, що перевищує звітний.
Узагальнена структуру інформаційних технологій підприємства, представлена на рис. 1.4.
Рис. 1.4 Узагальнена структура інформаційної технології підприємства
САПР (CAD/CAM) – системи автоматизованого проектування, виготовлення;
АС ТПП (САЕ) автоматизована система технологічної підготовки виробництва;
АСУ ТП (SKADA) автоматизовані системи управління технологічними процесами;
КІС (MRP, ERP) – корпоративні інформаційні системи;
ERP II - розширення ERP-системи за контури виробництва (тобто ERP +: CRM, B2B, DSS, SCM, PLM і ін.);
CRM - управління відносинами з клієнтами (WF - окремий випадок CRM);
B2B - електронна торговельна площадка ( «онлайновий бізнес»);
DSS - підтримка прийняття управлінських рішень;
SPSS - статистичний аналіз даних; OLAP - аналіз багатовимірних даних;
MIS - автоматизоване робоче місце (АРМ) керівника;
SCM - управління ланцюгами поставок;
PLM - управління життєвим циклом продукції;
HR - управління персоналом, можна розглядати як самостійну задачу, так і ту. входить до складу ERP;
WF - електронний документообіг (електронна пошта);
УП - управління виробництвом;
ПУ - первинний облік; ПФ - планування і бюджетування;
КУ - комерційний облік; СУ - складський облік;
БО - бухгалтерський облік; СТ - системи телекомунікацій.
Очевидно, що КІС – це складна система і для забезпечення її надійності потрібні спеціальні засоби аналізу стану системи в процесі експлуатації:
• аналіз алгоритмів;
• аналіз статистики: кількість записів, документів, проводок, обсяг дискової пам'яті;
• журнал виконаних операцій;
• список працюючих станцій, внутрішньо системна пошта.
Деякі фахівці розглядають вкладення засобів у створення КІС як довготривалі інвестиції, при цьому великого значення набувають рівень і якість обслуговування, що надається розробником. Для замовника оптимальною є ситуація, коли він, звернувшись до одного постачальника, отримує весь спектр послуг:
• постановка системи управління підприємством;
• консалтинг;
• рішення стосовно організації обліку і документообігу;
• навчання персоналу замовника;
• впровадження КІС в дослідну та промислову експлуатацію;
• супровід системи протягом усього її життєвого циклу;
• проведення тематичних семінарів як з проблем методології та організації обліку, так і з питань використання КІС.
З наведеного переліку вимог видно, що створення корпоративної інформаційної системи - задача дуже складна, що вимагає чималих витрат.
1.2 ІНФОРМАЦІЙНЕ ОБСТЕЖЕННЯ ПІДПРИЄМСТВА
Перш ніж спробувати вибрати існуючі або створити власну ІС, а потім її впровадити її, необхідно проаналізувати, як працює підприємство (організація) в даний час. Для аналізу необхідно знати не тільки як працює підприємство в цілому і як воно взаємодіє із зовнішніми організаціями, замовниками і постачальниками, але і як організована діяльність на кожному робочому місці.
Відзначимо, що в сучасних ІС спостерігається сильна залежність можливості програми тих чи інших методів управління підприємством від наявності адекватних засобів їх інформаційної підтримки. Освоївши кошти накопичення та обробки інформації в певній галузі (Бухгалтерія 1С, SCADA-системи і т.д.), підприємство отримує в своє розпорядження новий вид ресурсів - «інформаційних». Якість (цінність) цих ресурсів безпосередньо залежить від якості «організації» інформації, що дозволяє ефективно вилучати і представляти потрібні відомості (дані), а також здійснювати різні перетворення над ними. Важливо відзначити, що в існуючих ІС, які підтримують управління підприємством, в основному зосереджена оперативна кількісна інформація про матеріальні, фінансові та людські ресурси (облік кадрів). Набагато менше уваги приділяється інформації про саму організацію, діяльність підприємства і знаннях, що лежать в її основі (цілях, стратегії, процеси, функції, бізнес-правилах і т.п.). Виходячи з вищесказаного, в основі побудови сучасної ІС управління підприємством повинна лежати модель підприємства, яка на різних рівнях структурує і формалізує знання про підприємство та його оточенні. Модель підприємства можна представити у вигляді схеми на рис. 1.5. В самому верху діаграми розташовується об'єкт «Місія», що описує такі речі, як створення самого підприємства або випуск нового типу продукції або модернізацію виробничого циклу або ще щось нове, що вноситься в діяльність підприємства. Місія породжує «Аналіз» ситуації. Аналіз має на увазі проведення аналізу ринку, попиту на товари і послуги, діяльності конкурентів та ін. Результатом аналізу є постановка нових цілей підприємства - об'єкт «Цілі». Для виконання цілей підприємства намічаються «Завдання», які необхідно вирішити для досягнення цілей.
Рис 1.5 Модель підприємства
Завдання, які вирішуються підприємством, визначають «Структуру організації». Нові ж завдання можуть привести до появи на підприємстві нових «Проектів» по розробці нових моделей виробів, нових типів послуг і т.д. Структура організації передбачає створення підрозділів і філій підприємства. У кожному підрозділі приймаються на роботу співробітники - «Виконавці». Результатами виконання проектів є також «Стандарти» підприємства і «Технічні умови» - опису «Процесів» виробництва нових виробів на підприємстві. Самі процеси складаються з послідовності «Операцій». При виконанні кожної операції можуть породжуватися документи про результати виконання операцій. Завданнями на підприємстві є також «Плани» з випуску продукції. Ці плани доводяться до виконавців у вигляді «Завдань». На підставі завдань виконавці виконують виробничі «Процеси».
Для забезпечення виконуваних виробничих процесів необхідні матеріальні ресурси - сировина, електроенергія, комплектуючі вироби та інша «Продукція», що отримується від «Постачальників». Але до її використання в процесах потрібно виконати вхідний «Контроль якості» отриманої при «Поставці» продукції, а для виконання поставки необхідно укласти «Договір з постачальником». Перед укладенням договору слід подивитися характеристики і ціни пропонованих до постачання комплектуючих в «Каталогах постачальника».
Результатами виробничих процесів будуть готова продукція і документи, що описують процес виробництва (наприклад, документи на кожен виріб, табелі обліку робочого часу, акти про списання комплектуючих виробів та ін.). Цей потік документів, що породжується процесами, необхідно враховувати і контролювати - хід виконання завдань виконавців і планів структурних підрозділів. За результатами контролю визначаються досягнуті «Рішення» в ході виконання поставлених перед підприємством завдань. За цим рішенням визначаються «Результати» досягнення цілей підприємства. На основі отриманих результатів необхідно знову провести аналіз діяльності підприємства, ініціювавши, можливо, при цьому нові місії. Далі знову по колу - намічаємо нові цілі.
Вироблена «Готова продукція» повинна пройти вихідний «Контроль якості» і далі після зберігання на «Складі готової продукції», якщо це необхідно, повинен бути «Збут» споживачам. Для збуту продукції випускаються «Каталоги продукції» (це такі ж каталоги постачальника, які підприємство просило від своїх постачальників, але на цей раз саме підприємство виступає в ролі постачальника і пропонує свої каталоги для потенційних клієнтів), в яких вказуються моделі виробів і типи послуг,
кількість збуваються виробів і їх ціни. Для кожного розділу каталогу передбачаються стандартні «Договори збуту», які укладаються з «Клієнтами» на основі «Шаблонів договорів». Шаблони договорів є окремим випадком «Шаблоном документів», які використовуються в різних виробничих операціях, а самі процеси придбання комплектуючих і збуту готової продукції - окремими випадками виробничих процесів. Виробничим процесом є також процес розробки нового проекту, тобто має сенс говорити про основну інформаційної петлі на підприємстві (Аналіз - Цілі - Завдання - Структура - Виконавці - Процеси - Документи - Облік і контроль - Рішення - Результати - Аналіз) і про бібліотеку процесів: закупівля комплектуючих, збут готової продукції, розробка нових проектів та ін.
Крім вищеназваних об'єктів, поза організацією є також «Виробники» комплектуючих виробів і послуг, під якими випускаються, і «Споживачі», які потенційно можуть стати клієнтами підприємства. Образно наведену вище діаграму можна розглядати як кільце, по якому безперервно крутиться інформація. На стадії виробничого процесу вона захоплює сировину, комплектуючі вироби, енергію в результаті чого з'являються нові готові вироби. Постачальники та клієнти є «відкритими інтерфейсами», що зв'язують підприємство з іншими такими ж підприємствами. Результатом таких зв'язків є обмін продукцією (в загальному випадку під продукцією будемо розуміти - товар, послуги, документи). Це свого роду живі організми, які взаємодіють між собою.
1.3 РЕІНЖИНІРИНГ І БІЗНЕС-ПРОЦЕСИ
У зв'язку з розвитком і широким впровадженням комунікаційних і мережних комп'ютерних технологій змінилися і принципи побудови інформаційних систем. Результатом такого розвитку стала поява корпоративних інформаційних систем (КІС). Такі системи представляють цілий комплекс програмно-апаратних засобів, який дозволяє автоматизувати бізнес-процеси та інформаційні потоки на підприємстві або організації з метою адекватного інформаційного забезпечення для підвищення ефективності процесу управління.
Перші класичні моделі створення КІС спиралися, як правило, на комплексну автоматизацію ключових виробничих, адміністративно-управлінських та організаційних функцій підприємств або організацій шляхом використання відповідної комп'ютерної інфраструктури та програмного забезпечення. Згодом стало ясно, що таке звуження функцій КІС не відповідає можливостям системи. Особливість створення і впровадження КІС полягає не стільки в автоматизації функціональних підсистем підприємства (організації), скільки в рішенні задач оптимізації бізнес-процесів і вдосконалення процесу організації управління.
З початку 1990-х рр. методичним спрямуванням, що вивчають питання організаційного розвитку систем та управління підприємствами і дає рішення по їх побудові, є реінжиніринг бізнес-процесів РБП (BPR - Business Process Reengineering). Автоматизація управління підприємством базується на реінжинірингові бізнес-процесів. Ті процеси, які на «заході» розглядаються під терміном реінжиніринг, в країнах СНГ традиційно розділяють на три поняття:
•організація виробництва;
• організація праці;
• організація управління.
Реінжиніринг бізнес-процесів є напрямом, що виник на стику двох різних сфер діяльності - управління (менеджменту) і інформатизації. Саме тому реінжиніринг вимагає нових специфічних засобів подання та обробки проблемної інформації, зрозумілих як менеджерам, так і розробникам інформаційних систем управління. Подібні засоби вимагають інтеграції ключових досягнень інформаційних технологій і створення відповідних інструментальних засобів підтримки реінжинірингу.
Вперше термін «реінжиніринг бізнес-процесів» був введений М. Хаммером в 1990 р в статті «Реінжиніринг: не автоматизовуйте - знищуйте», який визначає цей вид діяльності як «фундаментальне перепроектування бізнес-процесів підприємств з метою досягнення корінних покращень в основних актуальних показниках їх діяльності: вартість, якість, послуги і темпи ». За кілька років реінжиніринг перетворився в одну з провідних і активно розвиваються галузей інформатики.
Сьогодні починається просування консалтингових послуг та інструментаріїв реінжинірингу і на український ринок. Вітчизняна практика застосування інформаційних технологій управління показала, що цей метод необхідний, особливо в умовах проведення глобальної економічної реформи і активного впровадження України в світову економічну систему.
Хаммер М. розглядає BPR як революцію в бізнесі, яка знаменує відхід від базових принципів побудови підприємств і перетворює конструювання бізнесу в інженерну діяльність. Можливість такої революції обумовлена, в першу чергу, новітніми досягненнями в області інформаційних технологій, фахівці якої починають відігравати провідну роль в конструюванні бізнесу. Саме інформації, інформаційних потоків, що відображає всі виробничі та управлінські процеси на підприємстві, способам її обробки і аналізу приділяється особлива увага. Однією з основних особливостей BPR є орієнтація реінжинірингу не на функції, а на процеси. Причому з усіх концепцій менеджменту, заснованих на процесах, BPR розглядається як найбільш ефективна, революційність якої обумовлена сучасним станом інформаційних технологій. Існують і інші методи, які можна розглядати або як окремі випадки BPR (якщо в основі цих методів лежить управління процесами), або як автономні концепції (якщо вони базуються на інших принципах):
• автоматизація бізнес-процесів (business process automation – BPA). Автоматизація призводить лише до прискорення існуючих бізнес-процесів. Використовуючи інформаційні технології, BPA автоматизує існуючий процес з усіма його недоліками і не ставить перед собою завдання проектування нового процесу для кардинального підвищення ефективності;
• реінжиніринг програмного забезпечення. На основі сучасних технологій виробляє переписування застарілих інформаційних систем без зміни самих автоматизованих процесів;
• реорганізація (reorganizing) підприємства. Дана концепція має справу тільки з організаційними структурами, а не з процесами;
• поліпшення якості (quality improvement – QI), глобальне управління якістю (total quality management – TQM). Хоча управління якістю відводить центральну роль бізнес-процесів, даний метод не приймає наявні процеси і намагається їх поліпшити, не змінюючи їх на нові.
Реінжиніринг заснований на концепції перервного (дмскретного) мислення у відшуканні застарілих правил і фундаментальних припущень, на яких будувалася робота, і рішучий розрив зв’язків з ними. Не можна досягти кардинального підвищення продуктивності просто автоматизацією існуючого процесу. Скоріше, слід перевірити обґрунтованість існуючих припущень і відмовитися від старих правил, які, власне, і викликають недостатню продуктивність.
Базовими поняттями BPR є бізнес-процес, бізнес-система, ділова процедура:
Бізнес - система – масив взаємоповязаних бізнес-процесів, кінцевою метою якого є випуск продукції. Під продукцією розуміють товари, послуги і документи.
Бізнес-процес – це горизонтальна ієрархія внутрішніх і залежних між собою функціональних дій, кінцевою метою яких є випуск продукції або окремих її компонентів.
Ділова процедура – це функція, завдання, ланцюг подій, що відбуваються протягом певного проміжку часу і володіють пізнаваним результатом.
Існують наступні категорії бізнес-процесів:
• процеси, що безпосередньо забезпечують випуск продукції;
• процеси планування і управління;
• ресурсні процеси;
• процеси перетворення.
Бізнес-процес характеризується:
• існуючою технологією реалізації бізнес-процесу;
• існуючою структурою бізнес-системи;
• засобами автоматизації, обладнанням, механізмами і т. п., що забезпечують реалізацію процесу.
Основними показниками оцінки ефективності бізнес-процесів є:
• кількість виробленої продукції заданої якості, сплачене за певний інтервал часу;
• кількість споживачів продукції;
• кількість типових операцій, які необхідно виконати при виробництві продукції за певний інтервал часу;
• вартість витрат виробництва продукції;
• тривалість виконання типових операцій;
• капіталовкладення у виробництво продукції.
Реінжиніринг бізнес-процесів базується на таких основних принципах:
• кілька робочих процедур поєднуються в одну, тобто відбувається горизонтальне стиснення процесу (за наявними оцінками, горизонтальне стиснення прискорює виконання процесу приблизно в 10 разів);
• виконавці приймають самостійні рішення, тобто здійснюється не тільки горизонтальне, але і вертикальне стискування процесів (наділення співробітників великими повноваженнями і збільшення ролі кожного з них призводить до значного підвищення їх віддачі);
• процеси мають різні варіанти виконання (той чи інший варіант вибирається в залежності від конкретної ситуації, стану і т. д.);
• робота виконується в тому місці (підрозділі, відділі), де це доцільно (усувається зайва інтеграція, що призводить до підвищення ефективності процесу в цілому);
• зменшується кількість перевірок і керуючих впливів;
• мінімізується кількість погоджень шляхом скорочення зовнішніх точок контакту;
• єдина точка контакту забезпечується уповноваженим менеджером (в тих випадках, коли кроки процесу або складні, або розподілені таким чином, що їх не вдається об'єднати силами невеликої команди).
Успішне використання принципу «безперервного поліпшення» бізнес-процесів (BPI) ґрунтується на перетині трьох областей знань (рис. 1.6).
Рис.1.6 Області знань
Область А - розвиток інформаційних технологій:
• використання професійних операційних систем (для серверів баз даних) і персональних комп'ютерів;
• використання професійних систем управління базами даних (СКБД);
• використання ERP-систем як ядра інтегрованої ІС підприємства;
• використання кооперативних технологій, що забезпечують комп'ютерну підтримку паралельної узгодженої роботи групи ( «команди») співробітників над одним проектом, документом і т.п .;
• використання телекомунікації, що дозволяє виключити передачу паперових документів і особистих зустрічей, звести до мінімуму необхідність переїздів для проведення нарад;
• використання систем управління знаннями для організації сховища і пошуку неструктурованих-них документів.
Область В - розвиток бізнес-платформ, що включають:
• методики управління якістю (тобто цілісну ідеологію управління підприємством) на базі стандартів ISO серії 9000;
• методики організації операційного менеджменту (ERP-стандарти);
• методики управління вимогами та конструкторськими розробками (CALS-стандарти);
Область С визначає «психологію праці» і спрямована на вирішення наступних завдань:
• впровадження принципу «лідерства» (усунення недоліків виробничої системи, а не окремих працівників);
• впровадження принципу «залученості працівників» (підвищення значущості та ініціативності кожного працівника);
• зняття бар'єрів між виробничими підрозділами, організація групової «артеріальної роботи»; утворення так званих «плоских» робочих груп, які використовують адгократію ( «адгократія» - компетентна бюрократія) способи управління, які спираються на інформаційні технології та організовують динамічний та неформальний розподіл прав і обов'язків співробітників групи;
• формування корпоративної культури та підвищення адгократію в організації;
• впровадження філософії тотального управління якістю на всіх робочих місцях (TQM);
• впровадження філософії організації виробничих процесів «точно вчасно» на всіх робочих місцях.
Відзначимо, що реінжиніринг не є модною тенденцією, це наслідок жорстокої конкурентної боротьби, витримати яку можна тільки шляхом впровадження нових, наукомістких інноваційних технологій. Більшість підприємств (організацій), які проводили реінжиніринг свого бізнесу, були просто змушені це зробити, опинившись перед лицем кризи.
1.4 СТАНДАРТИ ОПИСУ, АНАЛІЗУ І РЕОРГАНІЗАЦІЇ БІЗНЕС-ПРОЦЕСІВ
Світовий досвід свідчить, що впровадження на підприємстві ІС повинно передувати серйозне функціонально-інформаційне обстеження підприємства, з метою визначення оптимальності бізнес-процесів, розподілу ресурсів між функціями і т. д.
Поняття «моделювання бізнес-процесів» прийшло в побут більшості аналітиків одночасно з явищем на ринку складних програмних продуктів, призначених для систем комплексної автоматизації управління підприємством. Подібні системи завжди мають на увазі проведення глибокого передпроектного обстеження діяльності. Результатом цього обстеження є експертний висновок, у якому окремими пунктами виносяться рекомендації щодо усунення «вузьких місць» в управлінні діяльністю. На підставі даного висновку, безпосередньо перед проектом впровадження системи автоматизації, проводиться так звана реорганізація бізнес-процесів, іноді досить серйозна і болюча для компанії. Це і природно, що склався роками колектив завжди складно змусити «думати по-новому». Подібні комплексні обстеження підприємств є складними та суттєво відрізняються від випадку до випадку завданнями. Для рішення подібних завдань моделювання складних систем існують добре обкатані методології і стандарти. До таких стандартів відносяться методології сімейства IDEF. З їх допомогою можна ефективно відображати і аналізувати моделі діяльності широкого спектру складних систем в різних розрізах. При цьому широта і глибина обстеження процесів в системі визначається самим розробником, що дозволяє не перевантажувати створювану модель зайвими даними.
Зараз до сімейства IDEF можна віднести такі стандарти:
1) IDEF0 – методологія функціонального моделювання (Керівний документ Держстандарту РФ «Методологія функціонального моделювання IDEF0»). Метод IDEF0 призначений для функціонального моделювання, тобто моделювання виконання функцій об'єкта шляхом створення описової графічної моделі, що показує що, як і ким робиться в рамках функціонування підприємства. Функціональна модель являє собою структуроване зображення функцій виробничої системи чи середовища, інформації та об'єктів, що зв'язують ці функції;
2) IDEF1 – методологія моделювання інформаційних потоків усередині системи, що дозволяє відображати і аналізувати їх структуру і взаємозв'язки;
3) IDEF1X (IDEF1 Extended) – методологія побудови реляційних структур. IDEF1X відноситься до типу методологій «Сутність-зв'язок» (ER – Entity-Relationship) і, як правило, використовується для моделювання реляційних баз даних, що мають відношення до розглянутої системи;
4) IDEF2 – методологія динамічного моделювання розвитку систем. У зв'язку з досить серйозними складностями аналізу динамічних систем від цього стандарту практично відмовилися, і його розвиток зупинився на самому початковому етапі. Проте в даний час застосовуються алгоритми та їх комп’ютерні реалізації, що дозволяють перетворювати набір статичних діаграм IDEF0 в динамічні моделі, побудовані на базі «розфарбованих мереж Петрі» (CPN – Color Petri Nets);
5) IDEF3 – методологія документування процесів, що відбуваються в системі, яка використовується, наприклад, при дослідженні технологічних процесів на підприємствах. З допомогою IDEF3 описуються сценарій і послідовність операцій для кожного процесу. IDEF3 має прямий взаємозв'язок з методологією IDEF0 – кожна функція (функціональний блок) може бути представлена у вигляді окремого процесу засобами IDEF3;
6) IDEF4 – методологія побудови об'єктно-орієнтованих систем. Кошти IDEF4 наочно відображають структуру об'єктів і закладені принципи їх взаємодії, тим самим дозволяючи аналізувати й оптимізувати складні об'єктно-орієнтовані системи;
7) IDEF5 – методологія онтологічного дослідження складних систем. З допомогою методології IDEF5 онтологія системи може бути описана за допомогою певного словника термінів і правил, на підставі яких можуть бути сформовані достовірні твердження про стан розглянутої системи в певний момент часу. На основі цих тверджень формуються висновки про подальший розвиток системи і виробляється її оптимізація.
Розглянемо найбільш часто використовувану методологію функціонального моделювання IDEF0. Методологію IDEF0 можна вважати наступним етапом розвитку добре відомого графічної мови опису функціональних систем SADT (Structured Analysis and Design Teqnique).
1.6. Методологія функціонального моделювання SADT
Побудова SADT-моделі починається з представлення всієї системи у вигляді найпростішої компоненти – одного блоку і дуг, що зображують інтерфейси з функціями поза системою. Оскільки єдиний блок представляє всю систему як єдине ціле, ім'я, вказане в блоці, є загальним. Це вірно і для інтерфейсних дуг – вони також представляють повний набір зовнішніх інтерфейсів системи в цілому. Результатом застосування методології SADT є модель, яка складається з діаграм , фрагментів текстів та глосарію, які мають посилання один на одного. Діаграми – головні компоненти моделі, всі функції ІС і інтерфейси на них представлені як блоки і дуги. Місце з'єднання дуги з блоком визначає тип інтерфейсу. Керуюча інформація входить у блок зверху, у той час як інформація, яка підлягає обробці, показано з лівої сторони блоку, а результати виходу показано з правого боку. Механізм (людина або автоматизована система), що здійснює операцію, представляється дугою, що входить в блок знизу (рис. 1.7).
Рис. 1.7 Функціональний блок та інтерфейси дуги
Однією з найбільш важливих особливостей методології SADT є поступове введення все більших рівнів деталізації по мірі створення діаграм, що відображають модель. На рис. 1.8, де наведено чотири діаграми та їх взаємозв'язки, показана структура SADT-моделі. Кожен компонент моделі може бути декомпозований на іншій діаграмі.
Рис.1.8 Структура SADT- моделі. Декомпозиція діаграм.
Кожна діаграма ілюструє «внутрішню будову» блоку на батьківській діаграмі. Потім блок, який представляє систему в якості єдиного модуля, деталізується на іншій діаграмі за допомогою декількох блоків, сполучених інтерфейсними дугами. Ці блоки представляють основні підфункції вихідної функції. Дана декомпозиція виявляє повний набір підфункцій, кожна з яких представлена як блок, межі якої визначено інтерфейсними дугами. Кожна з цих підфункцій може бути декомпозована подібним чином для більш детального уявлення. У всіх випадках кожна підфункція може містити тільки ті елементи, які входять у вихідну функцію. Крім того, модель не може опустити якісь елементи, тобто, як уже зазначалося, батьківський блок і його інтерфейси забезпечують контекст. До нього не можна нічого додати, і з нього не може бути нічого видалено. Модель SADT представляє собою серію діаграм із супровідною документацією в якій розбивають складний об'єкт на складові частини, що представлені у вигляді блоків. Деталі кожного з основних блоків показані у вигляді блоків на інших діаграмах. Кожна детальна діаграма є декомпозицією блоку з більш загальної діаграми. На кожному кроці декомпозиції більш загальна діаграма називається батьківської ще більш детальної діаграми.
Дуги, що входять в блок і виходять з нього на діаграмі верхнього рівня, є точно тими ж самими, що і дуги, що входять в діаграму нижнього рівня і виходять з неї, тому що блок і діаграма представляють одну і ту ж частину системи. На рис. 1.9 - 1.11 представлені різні варіанти виконання функцій і з'єднання дуг з блоками.
Рис.1.9 Одночасне виконання
Рис.1.10 Приклад деталізації
Рис 1.11 Приклад зворотнього зв’язку
Деякі дуги приєднані до блоків діаграми обома кінцями, у інших же один кінець залишається не приєднаним. Не приєднані дуги відповідають входам, управлінням і виходів батьківського блоку. Джерело чи одержувач цих прикордонних дуг може бути виявлений тільки на батьківській діаграмі. Не приєднані кінці повинні відповідати дугам на вихідній діаграмі. Всі граничні дуги повинні продовжуватися на батьківській діаграмі, щоб вона була повною і достовірною.
На SADT-діаграмі не вказані явно ні послідовність, ні час. Зворотні зв'язки, ітерації, процеси що продовжуються і накладання (по часу) функції можуть бути зображені за допомогою дуг. Зворотні зв'язки можуть виступати у вигляді коментарів, зауважень, виправлень і т. д. (рис. 1.11).
Як було зазначено, механізми (дуги з нижньої сторони) показують засоби, за допомогою яких здійснюється виконання функцій. Механізм може бути людиною, комп'ютером або будь-яким іншим пристроєм, який допомагає виконувати цю функцію (рис. 1.12).
Рис 1.12 Приклад механізму
Кожен блок на діаграмі має свій номер. Блок будь діаграми може бути далі описаний діаграмою нижнього рівня, яка, в свою чергу, може бути далі деталізована за допомогою необхідного числа діаграм. Таким чином, формується ієрархія діаграм.
Кожен блок на діаграмі має свій номер. Блок будь діаграми може бути далі описаний діаграмою нижнього рівня, яка, в свою чергу, може бути далі деталізована за допомогою необхідного числа діаграм. Таким чином, формується ієрархія діаграм.
Одним з важливих моментів при проектуванні ІС за допомогою методології SADT є точна узгодженість типів зв'язків між функціями. Розрізняють принаймні шість типів зв'язування.
Нижче кожен тип зв'язку коротко визначено і проілюстрований за допомогою типового прикладу з SADT.
Випадкові зв'язки виникають, коли конкретний зв'язок між функціями малий або повністю відсутній. Це відноситься до ситуації, коли імена даних на SADT-дугах в одній діаграмі мають малий зв'язок один з одним. Крайній варіант цього випадку показаний на рис. 1.14.
Рис 1.13 Ієрархія діаграм
Рис.14 Випадкова зв'язність
1) Тип логічної зв'язності. Логічне зв'язування відбувається тоді, коли дані і функції збираються разом внаслідок того, що вони потрапляють в загальний клас або набір елементів, але необхідних функціональних відносин між ними не виявляється.
(2) Тип тимчасової зв'язності. Пов'язані за часом елементи виникають внаслідок того, що вони представляють функції, пов'язані в часі, коли дані використовуються одночасно або функції включаються паралельно, а не послідовно.
(3) Тип процедурної зв'язності. Процедурно-зв'язані елементи з'являються згрупованими разом внаслідок того, що вони виконуються протягом однієї і тієї ж частини циклу або процесу. Приклад процедурно-пов'язаної діаграми наведено на рис. 1.15.
(4) Тип комунікаційної зв'язності. Діаграми демонструють комунікаційні зв'язки, коли блоки групуються внаслідок того, що вони використовують одні і ті ж вхідні дані і / або виробляють одні й ті ж вихідні дані (рис. 1.16).
Рис.1.5 Приклад процедурно-зв’язної діаграми
Рис.1.16 Комунікаційна зв’язність
(5) Тип послідовної зв'язності. На діаграмах, що мають послідовні зв'язки, вихід однієї функції служить вхідними даними для наступної функції. Зв'язок між елементами діаграми є більш тісним, ніж на розглянутих вище рівнях зв'язок, оскільки моделюються причинно-наслідкові залежності (рис. 1.17).
(6) Тип функціональної зв'язаності. Діаграма відображає повну функціональну зв'язність, при наявності повної залежності однієї функції від іншої. Діаграма, яка є чисто функціональною, не містить чужорідних елементів, що належать до послідовного або більш слабкого типу зв'язності. Одним із способів визначення функціонально пов'язаних діаграм є розгляд двох блоків, пов'язаних через керуючі дуги, як показано на рис. 1.18.
Рис 1.17 Послідовна зв’язність
Рис.1.18 Функціональна зв’язність
Таблиця 1. Типи зв’язків
1.7. Стандарт IDEF0
Історично IDEF0 як стандарт був розроблений в 1981 р в рамках великої програми автоматизації промислових підприємств, яка носила позначення ICAM (Integrated Computer Aided Manufacturing) і була запропонована департаментом ВВС США. Власне сімейство стандартів IDEF успадкувало своє про- значення від назви цієї програми (IDEF = ICAM DEFinition). В процесі практичної реалізації учасники програми ICAM зіткнулися з необхідністю розробки нових методів аналізу процесів взаємодії в промислових системах. При цьому, крім вдосконаленого набору функцій для опису бізнес-процесів, однією з вимог до нового стандарту була наявність ефективної методології взаємодії в рамках «аналітик-фахівець». Іншими словами, новий метод повинен був забезпечити групову роботу над створенням моделі з безпосередньою участю всіх аналітиків і фахівців, зайнятих в рамках проекту. C 1981 р стандарт IDEF0 зазнав кілька незначних змін, в основному обмежує характеру, і остання його редакція була випущена в грудні 1993 р Національним Інститутом за Стандартами та Технологій США (NIST).
В основі методології лежать чотири основні поняття. Першим з них є поняття функціонального блоку (Activity Box). Функціональний блок графічно зображується у вигляді прямокутника (рис. 1.19) і уособлює собою деяку конкретну функцію в рамках даної системи. За вимогами стандарту назва кожного функціонального блоку має бути сформульовано в дієслівної формі (наприклад, «Виробляти послуги», а не «виробництво послуг»).
Рис. 1.19 Функціональний блок
Кожна з чотирьох сторін функціонального блоку має своє певне значення (роль), при цьому:
• верхня сторона має значення «Управління» (Control);
• ліва сторона має значення «Вхід» (Input);
• права сторона має значення «Вихід» (Output);
• нижня сторона має значення «Механізм» (Mechanism).
Кожен функціональний блок в рамках єдиної даної системи повинен мати свій унікальний ідентифікаційний номер.
Другим поняттям методології IDEF0 є поняття інтерфейсної дуги (Arrow). Інтерфейсні дуги часто називають потоками або стрілками. Інтерфейсна дуга відображає елемент системи, який обробляється функціональним блоком або надає інший вплив на функцію, відображену даними функціональним блоком.
Графічним відображенням інтерфейсної дуги є односпрямованим стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування повинно бути оборотом іменника.
Графічним відображенням інтерфейсної дуги є односпрямованим стрілка. Кожна інтерфейсна дуга повинна мати своє унікальне найменування (Arrow Label). На вимогу стандарту, найменування повинно бути оборотом іменника.
Залежно від того, до якої з сторін підходить дана інтерфейсна дуга, вона носить назву «входить», «виходить» або «керуючої». Крім того, «джерелом» (початком) і «приймачем» (кінцем) кожної функціональної дуги можуть бути тільки функціональні блоки, при цьому «джерелом» може бути тільки вихідна сторона блоку, а «приймачем» - будь-яка з трьох, що залишилися.
Необхідно відзначити, що будь-який функціональний блок (рис. 1.19) за вимогами стандарту повинен мати, принаймні, одну керуючу інтерфейсу дугу і одну вихідну. Це і зрозуміло - кожен процес повинен відбуватися за якимись правилами (що відображається керуючої дугою) і повинен видавати деякий результат (що виходить дуга). При побудові IDEF0-діаграм важливо правильно відокремлювати інтерфейсі дуги які входять від керівників, що часто буває непросто. Наприклад, на рис. 1.20 зображений функціональний блок «Обробити заготовку». У реальному процесі робочого, що проводить обробку, видають заготовку і технологічні вказівки по обробці (або правила техніки безпеки при роботі з верстатом). Помилково може здатися, що і заготовка і документ з технологічними вказівками є вхідними об'єктами, проте це не так. Насправді в цьому процесі заготовка обробляється за правилами, які відображені в технологічних вказівках, які повинні відповідно зображуватися керуючої інтерфейсною дугою.
Рис.1.20 Функціональний блок «Обробити заготовку»
Інша справа, коли технологічні вказівки обробляються головним технологом і в них вносяться зміни (рис. 1.21). У цьому випадку вони відображаються вхідною інтерфейсною дугою, а керуючим об'єктом є, наприклад, нові промислові стандарти (стандарт підприємства), виходячи з яких виробляються ці зміни.
Наведені вище приклади підкреслюють зовні схожу природу входять і керуючих інтерфейсних дуг, проте для систем одного класу завжди є певні розмежування. Наприклад, в разі розгляду підприємств і організацій існують п'ять основних видів об'єктів: матеріальні потоки (деталі, товари, сировина і т.д.), фінансові потоки (готівкові і безготівкові, інвестиції і т.д.), потоки доку- ментів (комерційні , фінансові та організаційні документи), потоки інформації (інформація, дані про наміри, усні розпорядження і т.д.) і ресурси (співробітники, верстати, машини і т.д.). При цьому в різних випадках вхідними та вихідними інтерфейсними дугами можуть відображатися всі види об'єктів; ті що керують - тільки пов'язані з потокам документів та інформації, а дугами-механізмами - тільки ресурси.
Рис. 1.21 Функціональний блок «Корекція технологічних вказівок».
Обов'язкова наявність керуючих інтерфейсних дуг є одним з головних відмінностей стандарту IDEF0 від інших методологій класів DFD (Data Flow Diagram) і WFD (Work Flow Diagram).
Третім основним поняттям стандарту IDEF0 є декомпозиція (Decomposition). Принцип декомпозиції застосовується при розбитті складного процесу на складові його функції. При цьому рівень деталізації процесу визначається безпосередньо розробником моделі.
Декомпозиція дозволяє поступово і структуровано представляти модель системи у вигляді ієрархічної структури окремих діаграм, що робить її менш перевантаженою і легко засвоюваній.
Модель IDEF0 завжди починається з представлення системи як єдиного цілого - одного функціонального блоку з інтерфейсними дугами, що тягнуться за межі даної області. Така діаграма з одним функціональним блоком називається контекстної діаграмою і позначається ідентифікатором «А-0».
У пояснювальному тексті до контекстної діаграмі повинна бути вказана мета (Purpose) побудови діаграми у вигляді короткого опису і зафіксована точка зору (Viewpoint).
Визначення та формалізація мети розробки IDEF0-моделі є вкрай важливим моментом. Фактично мета визначає відповідні області в досліджуваній системі, на які необхідно фокусуватися в першу чергу. Наприклад, якщо моделюється діяльність підприємства з метою побудови в подальшому на базі цієї моделі інформаційної системи, то ця модель буде істотно відрізнятися від тієї, яку б розробляли для того ж самого підприємства, але вже з метою оптимізації логістичних ланцюжків.
Точка зору визначає основний напрямок розвитку моделі та рівень необхідної деталізації. Чітке фіксування точки зору дозволяє розвантажити модель, відмовившись від деталізації і дослідження окремих елементів, які не є необхідними, виходячи з обраної точки зору на систему. Наприклад, функціональні моделі одного і того ж підприємства з точок зору головного технолога і фінансового директора будуть істотно відрізнятися за спрямованістю їх деталізації. Це пов'язано з тим, що в кінцевому підсумку фінансового директора не цікавлять аспекти обробки сировини на виробничому обладнанні, а головному технологу ні до чого промальовані схеми фінансових потоків. Правильний вибір точки зору істотно скорочує тимчасові витрати на побудову кінцевої моделі підприємства. У процесі декомпозиції функціональний блок, який в контекстної діаграмі відображає систему як єдине ціле, піддається деталізації на іншій діаграмі. Отримана діаграма другого рівня містить функціональні блоки, що відображають головні підфункции функціонального блоку контекстної діаграми, і називається дочірною (Child diagram) по відношенню до нього (кожен з функціональних блоків, що належать дочірній діаграмі, відповідно називається дочірнім блоком - Child Box). У свою чергу, функціональний блок-предок називається батьківським блоком по відношенню до дочірньої діаграмі (Parent Box), а діаграма, до якої він належить - батьківською діаграмою (Parent Diagram). Кожна з підфункций дочірньої діаграми може бути далі деталізована шляхом аналогічної декомпозиції відповідного їй функціонального блоку. Важливо відзначити, що в кожному разі декомпозиції функціонального блоку все інтерфейсні дуги, що входять у цей блок або виходять з нього, фіксуються на дочірньої діаграмі. Цим досягається структурна цілісність IDEF0-моделі. Слід звернути увагу на взаємозв'язок нумерації функціональних блоків і діаграм - кожен блок має свій унікальний порядковий номер на діаграмі (цифра в правому нижньому кутку прямокутника), а позначення під правим кутом вказує на номер дочірньої для цього блоку діаграми. Відсутність цього позначення говорить про те, що декомпозиції для даного блоку не існує.
Часто бувають випадки, коли окремі інтерфейсні дуги не має сенсу продовжувати розглядати в дочірніх діаграмах нижче якогось певного рівня в ієрархії або навпаки - окремі дуги не мають практичного сенсу вище якогось рівня. Наприклад, інтерфейсную дугу, яка зображує «деталь» на вході в функціональний блок «Обробити на токарному верстаті» не має сенсу відображати на діаграмах більш високих рівнів - це буде тільки перевантажувати діаграми і робити їх складними для сприйняття. З іншого боку, трапляється необхідність позбутися від окремих «концептуальних» інтерфейсних дуг і не деталізувати їх глибше деякого рівня. Для вирішення подібних завдань в стандарті IDEF0 передбачено поняття тунелювання. Позначення «тунелю» (Arrow Tunnel) у вигляді двох круглих дужок навколо початку інтерфейсної дуги означає, що ця дуга була успадкована від функціонального батьківського блоку і з'явилася (з «тунелю») тільки на цій діаграмі. У свою чергу, таке ж позначення навколо кінця (стрілки) інтерфейсної дуги в безпосередній близькості від блоку-приймача означає той факт, що в дочірньої по відношенню до цього блоку діаграмі ця дуга відображатися і розглядатися не буде. Найчастіше буває, що окремі об'єкти і відповідні їм інтерфейсні дуги не розглядаються на деяких проміжних рівнях ієрархії - в такому випадку вони спочатку «занурюються в тунель», а потім при необхідності «Повертаються з тунелю».
Останнім з понять IDEF0 є глосарій (Glossary). Для кожного з елементів IDEF0: діаграм, функціональних блоків, інтерфейсних дуг існуючий стандарт має на увазі створення і підтримку набору відповідних визначень, ключових слів, оповідних викладів і т.д., які характеризують об'єкт, відображений даними елементом. Цей набір називається глосарієм і є описом суті даного елемента. Наприклад, для керуючої інтерфейсної дуги «розпорядження про оплату» глосарій може містити перелік полів відповідного дузі документа, необхідний набір віз і т.д. Глосарій гармонійно доповнює наочний графічний мову, забезпечуючи діаграми необхідної додатковою інформацією.
Зазвичай IDEF0-моделі несуть в собі складну і концентровану інформацію, і для того, щоб обмежити їх перевантаженість і зробити легким для читання, у відповідному стандарті прийняті відповідні обмеження складності:
1) обмеження кількості функціональних блоків на діаграмі трьома - шістьма. Верхня межа (шість) змушує розробника використовувати ієрархії при описі складних предметів, а нижня межа (три) гарантує, що на відповідній діаграмі досить деталей, щоб виправдати її створення;
2) обмеження кількості відповідних до одного функціонального блоку (що виходять з одного функціонального блоку) інтерфейсних дуг чотирма.
Зрозуміло, строго слідувати цим обмеженням зовсім необов'язково, однак, як показує досвід, вони є досить практичними в реальній роботі.
Стандарт IDEF0 містить набір процедур, що дозволяють розробляти і погоджувати модель великою групою людей, що належать до різних областей діяльності, що моделюється. Зазвичай процес розробки є ітеративним і складається з наступних умовних етапів:
1. Створення моделі групою фахівців, що відносяться до різних сфер діяльності підприємства. Ця група в термінах IDEF0 називається авторами (Authors). Побудова первинної моделі є динамічним процесом, протягом якого автори опитують компетентних осіб про структуру різних процесів. На основі наявних положень, документів і результатів опитувань створюється чернетку (Model Draft) моделі.
2. Поширення чернетки для розгляду, погоджень і коментарів. На цій стадії відбувається обговорення чернетки моделі з широким спектром компетентних осіб (в термінах IDEF0 - читачів) на підприємстві. При цьому кожна з діаграм чорновий моделі письмово критикується і коментується, а потім передається автору. Автор, в свою чергу, також письмово погоджується з критикою або відкидає її з викладом логіки прийняття рішення і знову повертає відкоригований чернетку для подальшого розгляду. Цей цикл триває до тих пір, поки автори і читачі не прийдуть до єдиної думки.
3. Офіційне затвердження моделі. Затвердження узгодженої моделі відбувається керівником робочої групи в тому випадку, якщо у авторів моделі і читачів відсутні розбіжності з приводу її адекватності. Остаточною моделлю є узгоджене уявлення про підприємство (системі) з заданої точки зору і для заданої мети.
Наочність графічного мови IDEF0 робить модель цілком читається і для осіб, які не брали участі в проекті її створення, а також ефективної для проведення показів і презентацій. Надалі на базі побудованої моделі можуть бути організовані нові проекти, націлені на виробництво змін на підприємстві (в системі).
В останні роки інтерес в Росії до методологій сімейства IDEF неухильно зростає. При цьому інтерес до таких стандартів, як IDEF3-5 можна назвати теоретичним, а до IDEF0 цілком практично обґрунтованим. Власне кажучи, перші Case-засоби, що дозволяють будувати DFD- і IDEF0-діаграми, з'явилися на ринку ще в 1996 р.
Не секрет, що практично всі проекти обстеження і аналізу фінансової і господарської діяльності підприємств зараз в Україні, так чи інакше, пов'язані з побудовою автоматизованих систем управління. Завдяки цьому, стандарти IDEF в розумінні більшості стали умовно невіддільні від впровадження інформаційних технологій, хоча з їх допомогою часом можна ефективно вирішувати навіть невеликі локальні завдання, буквально за допомогою олівця і паперу.
При здійсненні складних проектів обстеження підприємств розробка моделей в стандарті IDEF0 дозволяє наочно і ефективно відобразити весь механізм діяльності підприємства в потрібному розрізі. Однак найголовніше - це можливість колективної роботи, яку надає IDEF0.
1.7. Стандарт IDEF1
Діяльність будь-якого підприємства можна представити як безперервну зміну стану фізичних та інтелектуальних об'єктів, що мають відношення до підприємства, таких як співробітники, засоби виробництва, вироблені продукти, ідеї, фінанси і т.д. Для ефективного управління цим процесом кожну зміну того чи іншого об'єкта повинна мати своє документальне відображення. Цими відображеннями служать особисті справи співробітників, звіти, рекламна продукція, службові записки тощо Їх сукупність назвемо інформаційною областю підприємства. Рух інформації (наприклад, документообіг) і зміна її назвемо інформаційними потоками. Очевидно, що будь-якому бізнес-процесу, а також будь-якій зміні фізичних об'єктів повинен відповідати певний інформаційний потік. Більш того, керівництво, при побудові стратегічних планів розвитку і управлінні діяльністю підприємства (видаючи накази, розпорядження і т.д.), фактично керується інформаційними потоками і вносить в них зміни, таким чином, здійснюючи інформаційний менеджмент.
Стандарт IDEF1 був розроблений як інструмент для аналізу і вивчення взаємозв'язків між інформаційними потоками в рамках комерційної діяльності підприємства. Метою подібного дослідження є доповнення і структуризація існуючої інформації і забезпечення якісного менеджменту інформаційними потоками. Необхідність у подібній реорганізації інформаційної галузі, як правило, виникає на початковому етапі побудови корпоративної інформаційної системи, і методологія IDEF1 дозволяє досить наочно виявити «чорні діри» і слабкі місця в існуючій структурі інформаційних потоків. Застосування методології IDEF1 як інструменту побудови наочної моделі інформаційної структури підприємства за принципом «Як повинно бути» дозволяє вирішити такі завдання:
• з'ясувати структуру і зміст існуючих потоків інформації на підприємстві;
• визначити, які проблеми, виявлені в результаті функціонального аналізу і аналізу потреб, викликані недоліком управління відповідною інформацією;
• виявити інформаційні потоки, що вимагають додаткового управління для ефективної реалізації моделі.
За допомогою IDEF1 відбувається вивчення існуючої інформації про різні об'єкти в області діяльності підприємства. Характерно те, що IDEF1-модель включає в розгляд не тільки автоматизовані компоненти, бази даних і відповідну їм інформацію, але також і реальні об'єкти, такі як самі співробітники, кабінети, телефони і т.д. Місія методології IDEF1 полягає в тому, щоб виявити і чітко постулювати потреби в інформаційному менеджменті в рамках комерційної діяльності підприємства. На відміну від методів розробки структур баз даних (наприклад, IDEF1X), IDEF1 є аналітичним методом і використовується переважно для виконання наступних дій:
• визначення самої інформації і структури її потоків, що має відношення до діяльності підприємства;
• визначення існуючих правил і законів, по яких здійснюється рух інформаційних потоків, а також принципів управління ними;
• з'ясування взаємозв'язків між існуючими інформаційними потоками в межах підприємства;
• виявлення проблем, що виникають внаслідок нестачі якісного інформаційного менеджменту.
Результати аналізу інформаційних потоків можуть бути використані для стратегічного і тактичного планування діяльності підприємства та покращення інформаційного менеджменту.
Однак основною метою використання методології IDEF1 все ж залишається дослідження руху потоків інформації та принципів управління ними на початковому етапі процесу проектування корпоративної інформаційно-аналітичної системи, яка сприятиме більш ефективному використанню інформаційного простору. Наочні моделі IDEF1 забезпечують базис для побудови потужної і гинув - кою інформаційної системи.
Методологія IDEF1 розділяє елементи структури інформаційної галузі, їх властивості та взаємозв'язки на класи. Центральним поняттям методології IDEF1 є поняття сутності. Клас сутностей являє собою сукупність інформації, накопиченої і зберігається в межах підприємства і відповідає певному об'єкту або групі об'єктів реального світу. Основними концептуальними властивості сутностей в IDEF1 є:
1) стійкість (інформація, що має відношення до тієї чи іншої сутності, постійно накопичується);
2) унікальність (будь-яка сутність може бути однозначно ідентифікована з іншої сутності). Кожна сутність має своє ім'я і атрибути. Атрибути являють собою характерні властивості і признаки об'єктів реального світу, що належать до певної сутності. Клас атрибутів являє собою набір пар, що складаються з імені атрибута і його значення для певної сутності. Атрибути, за якими можна однозначно відрізнити одну сутність від іншої, називаються ключовими атрибутами. Кожна сутність може характеризуватися кількома ключовими атрибутами. Клас взаємозв'язків у IDEF1 представляє собою сукупність взаємозв'язків між сутностями. Взаємозв'язок між двома окремими сутностями вважається існуючим в тому випадку, якщо клас атрибутів однієї сутності містить ключові атрибути іншої сутності. Кожен з вищеописаних класів має своє умовне графічне відображення згідно методології IDEF1.
На рис. 1.22 наведено приклад IDEF1-діаграми. На ній представлені дві сутності з іменами «Відділ» і «Працівник» та взаємозв'язок між ними з ім'ям «працює». Ім'я взаємозв'язку завжди виражається в дієслівної формі. Якщо між двома або кількома об'єктами реального світу не існує встановленої залежності, то, з точки зору IDEF1, між відповідними їм сутностями взаємозв'язок також відсутній.
Рис. 1.22 IDEF-діаграма
На закінчення варто ще раз зазначити, що стандарт IDEF1 є методом вивчення та аналізу на відміну від дуже схожого по термінології і семантику стандарту IDEF1X, призначеного для розробки структури реляційних баз даних і оперує з конкретними об'єктами фізичного світу.
1.9. Стандарт IDEF1X
IDEF1X є методом для розробки реляційних баз даних і використовує умовний синтаксис, спеціально розроблений для зручного побудови концептуальної схеми.
Відомо, що основним компонентом реляційних баз даних є таблиця. Таблиці використовуються для управління і зберігання інформації. Таблиці в реляційної СУБД складаються з рядків даних, однорідних за своєю природою. Іншими словами, кожен рядок таблиці описує один екземпляр деякої сутності, причому набір атрибутів кожного примірника постійний.
Припустимо, в базі даних зберігається інформація про покупців. Таблиця «покупець» містить 3 колонки і 4 рядки:
Таблиця 2. Реляційна база даних
Ім'я таблиці і імена її колонок складають структуру таблиці: customer (name, address, card_id). У реляційної СУБД всі значення даних є атомарними, тобто не можна в клітці таблиці зберігати список значень.
Таблиці в реляційної СУБД відповідають (не обов'язково збігаються в назві) сутностей, а колонки - атрибутам.
Концептуальною схемою назвемо універсальне представлення структури даних в рамках комерційного підприємства, незалежне від кінцевої реалізації бази даних і апаратної платформи. Будучи статичним методом розробки, IDEF1X спочатку не призначений для динамічного аналізу, проте, він іноді застосовується в цій якості як альтернатива методу IDEF1. Використання методу IDEF1X найбільш доцільно для побудови логічної структури бази даних після того, як всі інформаційні ресурси досліджені (скажімо, за допомогою методу IDEF1) і рішення про впровадження реляційної бази даних, як частини корпоративної інформаційної системи, було прийнято. Однак, не варто забувати, що ресурси моделювання IDEF1X спеціально розроблені для побудови реляційних інформаційних систем, і якщо існує необхідність проектування іншої системи, скажімо об'єктно-орієнтованої, то краще обрати інші методи моделювання. Існує кілька очевидних причин, за якими IDEF1X не слід застосовувати в разі побудови нереляційних баз даних. По-перше, IDEF1X вимагає від проектувальника визначити ключові атрибути, щоб відрізнити одну сутність від іншої, в той час як об'єктно - орієнтовані системи не вимагають завдання ключових атрибутів з метою ідентифікації об'єктів. По-друге, в тих випадках, коли більш ніж один атрибут є таким, що однозначно ідентифікує сутність, проектувальник повинен визначити один з цих атрибутів первинним ключем, а всі інші вторинними. І, таким чином, побудована проектувальником IDEF1X-модель і передана для остаточної реалізації програмісту є некоректною для застосування методів об'єктно-орієнтованої реалізації і призначена для побудови реляційної системи.
Хоча термінологія IDEF1X практично збігається з термінологією IDEF1, існує ряд фундаментальних відмінностей у теоретичних концепціях цих методологій. Сутність в IDEF1X описує собою сукупність або набір екземплярів, схожих за властивостями, але однозначно відрізняємося один від одного за одним або кількома ознаками. Кожен екземпляр є реалізацією суті. Таким чином, сутність в IDEF1X описує конкретний набір екземплярів реального світу, на відміну від сутності в IDEF1, яка представляє собою абстрактний набір інформаційних відображень реального світу. Прикладом суті IDEF1X може бути сутність СПІВРОБІТНИК, яка представляє собою всіх співробітників підприємства, а один з них, скажімо, Іванов Іван Іванович, є конкретною реалізацією цієї сутності. У прикладі, наведеному на рис. 1.22, кожен екземпляр сутності СПІВРОБІТНИК містить наступну інформацію: ID співробітника, ім'я співробітника, адресу співробітника і т.п. У IDEF1X-моделі ці властивості називаються атрибутами суті. Кожен атрибут містить тільки частину інформації про сутність.
Зв'язки в IDEF1X є посилання, з'єднання і асоціацію між сутностями. Зв'язки це суть дієслова, які показують, як співвідносяться суті між собою. Нижче наведено ряд прикладів зв'язку між сутностями:
Відділ <складається з> декількох СПІВРОБІТНИКІВ. Автобус <перевозить> декількох ПАСАЖИРІВ. Співробітник <пише> різні ЗВІТИ.
У всіх перерахованих прикладах взаємозв'язку між сутностями відповідають схемі «один-до-батьох». Це означає, що один екземпляр першої суті пов'язаний з декількома екземплярами другої суті. Причому перша сутність називається батьківської, а друга - дочірною. У наведених прикладах дієслова укладені в кутові дужки. Зв'язки відображаються у вигляді лінії між двома сутностями з точкою на одному кінці і дієслівної фразою, яка відображається над лінією. На рис. 1.22 наводиться графік залежності між СПІВРОБІТНИКОМ і ВІДДІЛОМ.
Відносини «багато-до-багатьох» зазвичай використовуються на початковій стадії розробки діаграми, наприклад, в діаграмі залежності сутностей і відображаються в IDEF1X у вигляді суцільної лінії з точками на обох кінцях. Так як відносини «багато-до-багатьох» можуть приховати інші бізнес-правила або обмеження, вони повинні бути повністю досліджені на одному з етапів моделювання. Наприклад, іноді відношення «Багато-до-багатьох» на ранніх стадіях моделювання ідентифікується неправильно, насправді представляючи два або кілька випадків відносин «один-до-батьох» між пов'язаними сутностями. Або, в разі необхідності зберігання додаткових відомостей про зв'язок «багато-до-багатьох», наприклад, дати або коментаря, такий зв'язок має бути замінена додаткової сутністю, що містить ці відомості. При моделюванні необхідно бути впевненим в тому, що всі відносини «багато-до-багатьох» будуть детально обговорені на більш пізніх стадіях моделювання для забезпечення правильного моделювання відносин. Сутність описується в діаграмі IDEF1X графічним об'єктом у вигляді прямокутника. На рис. 1.23 наведено приклад IDEF1X-діаграми. Кожен прямокутник, що відображає собою сутність, розділяється горизонтальною лінією на частину, в якій розташовані ключові поля, і частина, де розташовані неключові поля. Верхня частина називається ключовою областю, а нижня частина - областю даних. Ключова область об'єкта СПІВРОБІТНИК містить поле «Унікальний ідентифікатор співробітника», в області даних знаходяться поля «Ім'я співробітника», «Адреса співробітника», «Телефон співробітника» і т.д. Ключова область містить первинний ключ для сутності. Первинний ключ - це набір атрибутів, вибраних для ідентифікації унікальних екземплярів сутності. Атрибути первинного ключа розташовуються над лінією в ключовій області. Як випливає з назви, неключовий атрибут - це атрибут, який не був обраний ключовим. Неключові атрибути розташовуються під рискою, в області даних.
При створенні суті в IDEF1X-моделі одним з головних питань, на який потрібно відповісти, є: як можна ідентифікувати унікальну запис? Для цього потрібно унікальна ідентифікація кожного запису по суті для того, щоб правильно створити логічну модель даних. Нагадаємо, що сутності в IDEF1X завжди мають ключову область і тому в кожній сутності повинні бути визначені ключові атрибути.
Рис.1.23 Приклад IDEF1X-діаграми
Вибір первинного ключа для сутності є дуже важливим кроком і вимагає особливої уваги. В якості первинних ключів можуть бути використані кілька атрибутів або груп атрибутів. Атрибути, які можуть бути обрані первинними ключами, називаються кандидатами в ключові атрибути (потенційні атрибути). Кандидати в ключі повинні унікально ідентифікувати кожен запис суті. Відповідно до цього жодна з частин ключа не може бути: NULL, не заповнена або відсутня.
Наприклад, для того, щоб коректно використовувати сутність СПІВРОБІТНИК в IDEF1X-моделі даних (а пізніше в базі даних), необхідно мати можливість унікально ідентифікувати записи. Правила, за якими ви вибираєте первинний ключ зі списку передбачуваних ключів, дуже суворі, однак можуть бути застосовані до всіх типів баз даних та інформації. Правила встановлюють, що атрибути і групи атрибутів повинні:
Для наочного уявлення про те, як доцільно вибирати первинні ключі, наведемо такий приклад - виберемо первинний ключ для сутності СПІВРОБІТНИК:
Комбінація атрибутів «ім'я співробітника» і «дата народження співробітника» може виявитися вдалою для наших цілей і стати потрібним потенційним ключем.
Після проведеного аналізу можна назвати два потенційних ключа - перший «Номер співробітника» і комбінація, що включає поля «Ім'я співробітника» і «Дата народження співробітника». Так як атрибут «Номер співробітника» має найкоротші і унікальні значення, то він краще за інших підходить для первинного ключа.
При виборі первинного ключа для сутності розробники моделі часто використовують додатковий (сурогатний) ключ, тобто довільний номер, який унікальним чином визначає запис по суті. Атрибут «Номер співробітника» є прикладом сурогатного ключа. Сурогатний ключ найкраще підходить на роль первинного ключа тому, що є коротким і швидше за все ідентифікує примірники у об'єкті. До того ж сурогатні ключі можуть автоматично генеруватися системою так, щоб нумерація була суцільною, тобто без пропусків.
Потенційні ключі, які не вибрані первинними, можуть бути використані в якості вторинних або альтернативних. За допомогою альтернативних ключів часто відображають різні індекси доступу до даних в кінцевій реалізації реляційної бази.
Якщо суті в IDEF1X-діаграмі пов'язані, зв'язок передає ключ (або набір ключових атрибутів) дочірної сутності. Ці атрибути називаються зовнішніми ключами. Зовнішні ключі визначаються як атрибути первинних ключів батьківського об'єкта, передані дочірньому об'єкту через їх зв'язок. Передані атрибути називаються мігруючими.
При розробці моделі часто доводиться стикатися з сутностями, унікальність яких залежить від значень атрибута зовнішнього ключа. Для цих сутностей (для унікального визначення кожної сутності) зовнішній ключ повинен бути частиною первинного ключа дочірнього об'єкта. Дочірня сутність, унікальність якої залежить від атрибута зовнішнього ключа, називається залежною. У прикладі на рис. 1.23 сутність СПІВРОБІТНИК є залежною тому, що її ідентифікація залежить від сутності ВІДДІЛ.
Атрибути зображуються у вигляді списку імен усередині блоку сутності. Атрибути, що визначають первинний ключ, розміщуються нагорі списку і відділяються від інших атрибутів горизонтальній рисою (рис. 1.24).
Рис 1.24 Атрибути і первинні ключі
Рис. 1.25 Приклади зовнішніх ключів
Зовнішній ключ (Foreign Key, FK) зображується за допомогою приміщення всередину блоку сутності імен атрибутів, після яких слідують букви FK в дужках (рис. 1.25).
Зовсім суті далі класифікуються на сутності, які не можуть існувати без батьківської сутності, і сутності, які не можуть бути ідентифіковані без використання ключа батька (сутності, що залежать від ідентифікації). Сутність СПІВРОБІТНИК належить до другого типу залежних сутностей, так як співробітники можуть існувати і без відділу.
Навпаки, є ситуації, в яких сутність залежить від існування іншої сутності. Розглянемо дві сутності: ЗАПИТ, який використовується для відстеження запитів покупців, і ПОЗИЦІЯ ЗАПРОСА, яка відстежує окремі елементи в запиті. Зв'язок між цими двома сутностями може бути виражена у вигляді ЗАПИТ <містить> один або кілька ПОЗИЦІЙ ЗАПРОСА. В цьому випадку, ПОЗИЦІЯ ЗАПИТУ залежить від існування ЗАМОВЛЕННЯ.
Ті сутності, які не залежать при ідентифікації від інших об'єктів в моделі, називаються незалежними. У вищеописаному прикладі сутність ВІДДІЛ можна вважати незалежною. У IDEF1X незалежні сутності представлені у вигляді прямокутників, а залежні сутності представлені у вигляді закруглених прямокутників (рис. 1.26).
Рис. 1.26 Незалежні та залежні від ідентифікатора сутності
У IDEF1X концепція залежних і незалежних сутностей посилюється типом взаємозв'язків між двома сутностями. Якщо ви хочете, щоб зовнішній ключ передавався в дочірню сутність (і, в результаті, створював залежну сутність), то можете створити ідентифікуючий зв'язок між батьківської та дочірньої сутностями.
Ідентифікуючий взаємозв'язк позначаються суцільною лінією між сутностями (рис. 1.27). Неідентіфікуючі зв'язки (рис. 1.28), що є унікальними для IDEF1X, також пов'язують батьківську сутність з дочірньою і використовуються для відображення іншого типу передачі атрибутів зовнішніх ключів - передачі в область даних дочірньої сутності (під лінією).
Рис.1.27 Ідентифікуючий зв’язок
Неідентіфікуючий зв'язк відображаються пунктирною лінією між об'єктами. Так як передані ключі до ідентифікуючого зв'язку не є складовою частиною первинного ключа дочірньої сутності, то цей вид зв'язку не проявляється ні в одній ідентифікуючої залежності. В цьому випадку і ВІДДІЛ, і СПІВРОБІТНИК розглядаються як незалежні сутності.
Проте, взаємозв'язок може відображати залежність існування, якщо бізнес-правило для взаємозв'язку визначає те, що зовнішній ключ не може приймати значення NULL. Якщо зовнішній ключ повинен існувати, то це означає, що запис в дочірньої сутності може існувати тільки при наявності асоційованим з ним батьківським записом.
1.10 Стандарт IDEF3
IDEF3 є стандартом документування технологічних процесів, що відбуваються на підприємстві, і надає інструментарій для наочного дослідження і моделювання їх сценаріїв. Сценарієм (Scenario) назвемо опис послідовності змін властивостей об'єкта в рамках даного процесу (наприклад, опис послідовності етапів обробки деталі в цеху і зміна її властивостей після проходження кожного етапу). Виконання кожного сценарію супроводжується відповідним документообігом, який складається з двох основних потоків: документів, що визначають структуру і послідовність процесу (технологічних вказівок, описів стандартів і т.д.), і документів, що відображають хід його виконання (результатів тестів і експертиз, звітів про шлюб і т.д.). Для ефективного управління будь-яким технологічному процесом необхідно мати детальне уявлення про його сценарії і структурі супутнього документообігу. Засоби документування та моделювання IDEF3 дозволяють виконувати наступні завдання:
Існують два типи діаграм в стандарті IDEF3, що представляють опис одного і того ж сценарію технологічного процесу в різних ракурсах. Діаграми, що відносяться до першого типу, називаються діаграмами «Опису послідовності етапів процесу» (Process Flow Description Diagrams, PFDD), а до другого діаграмами «Стану об'єкта і його трансформацій в процесі» (Object State Transition Network, OSTN). Припустимо, потрібно описати процес фарбування деталі у виробничому цеху на підприємстві. За допомогою діаграм PFDD документуються послідовність і опис стадій обробки деталі в рамках досліджуваного технологічного процесу. Діаграми OSTN використовуються для ілюстрації трансформацій деталі, які відбуваються на кожній стадії обробки.
На наступному прикладі опишемо, як графічні засоби IDEF3 дозволяють документувати вищевказаний виробничий процес фарбування деталі. В цілому, цей процес складається безпосередньо з самої забарвлення, виробленої на спеціальному обладнанні, і етапу контролю її якості, який визначає, чи потрібно деталь забарвити заново (у разі невідповідності стандартам і виявлення шлюбу) або відправити її в далечінь обробку.
На рис. 1.29 зображена діаграма PFDD, що є графічним відображенням сценарію обробки деталі.
Рис. 1.29 Приклад PFDD діаграми
Прямокутники на діаграмі PFDD називаються функціональними елементами або елементами поведінки (Unit of Behavior, UOB) і позначають подію, стадію процесу або прийняття рішення. Кожен UOB має своє ім'я, що відображається в дієслівної формі, і унікальний номер. Стрілки або лінії є відображенням переміщення деталі між UOB-блоками в ході процесу. Лінії бувають наступних видів:
Об'єкт, позначений J1 – називається перехрестям (Junction). Перехрестя використовуються для відображення логіки взаємодії стрілок (потоків) при злитті і розгалуженні або для відображення безлічі подій, які можуть або повинні бути завершені перед початком наступної роботи. Розрізняють перехрестя для злиття (Fan-in Junction) і розгалуження (Fan-out Junction) стрілець.
Перехрестя не може використовуватися одночасно для злиття і для розгалуження. При внесенні перехрестя в діаграму необхідно вказати тип перехрестя. Класифікація можливих типів перехресть приведена в табл. 1.2.
Таблиця 1.2 Класифікація можливих типів перехресть
Сценарій, який відображається на діаграмі, можна описати в наступному вигляді. Деталь надходить в фарбувальний цех, підготовлена до фарбування. У процесі фарбування наноситься один шар емалі при високій температурі. Після цього проводиться сушка деталі, потім починається етап перевірки якості нанесеного шару. Якщо тест підтверджує недостатню якість нанесеного шару (недостатню товщину, неоднорідність і т. д.), то деталь заново пропускається через цех фарбування. Якщо деталь успішно проходить контроль якості, то вона відправляється в наступний цех для подальшої обробки.
Кожен функціональний блок UOB може мати послідовність декомпозицій і, отже, може бути деталізований з будь-якою необхідною точністю. Під декомпозицією розуміється уявлення кожного UOB з допомогою окремої IDEF3-діаграми. Наприклад, можна декомпозувати UOB «Забарвити Деталь», представивши його окремим процесом і побудувавши для нього свою PFDD-діаграму. При цьому ця діаграма буде називатися дочірньою по відношенню до зображеної на рис. 1.29, а та, відповідно – батьківської. Номери UOB дочірніх діаграм мають наскрізну нумерацію, тобто, якщо батьківський UOB має номер «1», то блоки UOB на його декомпозиції будуть відповідно мати номери «1.1», «1.2» і т. д. Застосування принципу декомпозиції в IDEF3 дозволяє структурувати описувати процеси з будь-яким необхідним рівнем деталізації.
Якщо діаграми PFDD – технологічний процес «З точки зору спостерігача, то інший клас діаграми IDEF3 OSTN дозволяє розглядати той же самий процес «З точки зору об'єкта». На рис. 1.30 представлено відображення процесу забарвлення з точки зору OSTN-діаграми. Стану об'єкта (у нашому випадку деталі) і зміни стану є ключовими поняттями OSTN-діаграми.
Стан об'єкта відображаються колами, а їх зміни - спрямованими лініями. Кожна ліня має посилання на відповідний функціональний блок UOB, в результаті якого відбулося відображуване нею зміна стану об'єкту.
1.11. Методологія функціонально-вартісного аналізу
Вважається, що функціонально-вартісний аналіз ФВА (ABC, Activity Based Costing) є досить складним для розуміння. Можливо, це пов'язано з тим, що існує дуже мало інформації, яка пояснює, що ж він власне з себе представляє .
Рис. 1.30 Приклад OSTN-діаграми
Метою цього параграфа є розкриття сутності функціонально-вартісного аналізу, простоти його застосування, а також виключення елемента загадковості, пов'язаного з ним. Функціонально-вартісний аналіз дозволяє виконати наступні види робіт:
Очевидно, що перераховані вище дії покращують якість бізнес-процесів. Підвищення якості бізнес-процесів здійснюється за рахунок проведення порівняльної оцінки і вибору раціональних (за вартісною або тимчасовому критерію) технологій виконання операцій або процедур. В основі управління, заснованого на функціях, лежать кілька аналітичних методів, що використовують ФВА-інформацію. Це – стратегічний аналіз, вартісний аналіз, часовий аналіз, аналіз трудомісткості, визначення цільової вартості та обчислення вартості, виходячи з життєвого циклу продукту чи послуги. Одним з напрямків використання принципів, засобів і методів ФВА є планування бюджету, засноване на функціях. Планування бюджету використовує ФВА-модель для визначення обсягу робіт і потреби в ресурсах, при цьому можна виділити два шляхи: • вибір пріоритетних напрямків діяльності, пов'язаних з стратегічними цілями; • розробка реалістичного бюджету. ФВА-інформація дозволяє приймати усвідомлені і цілеспрямовані рішення про розподіл ресурсів, що спираються на розуміння взаємозв'язків функцій і вартісних об'єктів, вартісних факторів і обсягу робіт. Розвитком ФВА-методу став метод функціонально-вартісного управління (ФСУ, Activity-Based Management). ФСУ – це метод, який включає управління витратами на основі застосування більш точного віднесення витрат на процеси і продукцію. Особливо звертаємо увагу на те, що ФСУ-метод дозволяє не тільки визначати витрати, але і керувати ними. Однак, не варто ставити знак рівності між управлінням і контролем. Дані ФВА/ФСУ використовуються більше для «передбачливий» моделювання, ніж для контролю. На сьогоднішній день використання даних про витрати для потреб контролю витісняється більш оперативною інформацією від TQM-методу, реалізованого у вигляді функцій статистичного контролю процесів (Statistical Process Control, SPC), або від інтегрованих інформаційних систем, що працюють в режимі реального часу. У процесі побудови функціонально-вартісних моделей вдалося встановити методологічну і технологічну взаємозв'язок між IDEF0 - і ФВА-моделями. Пов'язаність методів IDEF0 та ФВА полягає в тому, що обидва методу розглядають підприємство як безліч послідовно виконуваних функцій, а дуги входів, виходів, управління і механізмів IDEF0 - моделі відповідають вартісним об'єктів і ресурсів ФВА-моделі. На рис. 1.31 представлена концептуальна модель ФВА-методу, з якої чітко видно, що Ресурси (Витрати) у ФВА-моделі – це вхідні дуги, дуги управління і механізмів в IDEF0-моделі (див. рис. 1.19), Продукти (Вартісні об'єкти) ФВА-моделі – це вихідні дуги IDEF0-моделі, а Дії ФВА-методу – це Функції в IDEF0-моделі.
Рис. 1.31 Концептуальна схема ФВА –методу
На більш низькому рівні, а саме, рівні функціонального блоку (рис. 1.32), зв'язок IDEF0 - і ФВА-моделей базується дещо на інших.
Рис. 1.32. Функціональний блок та інтерфейсні дуги.
Принципи на яких базується зв'язок IDEF0 - і ФВА-моделей на більш низькому рівні, а саме на рівні функціонального блоку:
На закінчення наведемо класифікацію базових методологій для побудови моделей бізнес-процесів (інформаційної моделі КІС) (табл. 1.3).
Таблиця 1.3 Класифікація базових методологій
В результаті обстеження підприємства будується функціональна модель існуючої організації роботи AS-IS («як є»). На основі цієї моделі досягається консенсус між різними одиницями бізнесу з питань, хто що зробив, і що кожна одиниця бізнесу додає в процес. Модель AS-IS дозволяє з'ясувати, що слід зробити сьогодні перед тим, як вирішити, що слід зробити завтра. Впровадження інформаційної системи неминуче призведе до перебудови існуючих бізнес-процесів підприємства. Аналіз функціональної моделі дозволяє зрозуміти, де знаходяться найбільш «вузькі місця», у чому полягатимуть переваги нових бізнес-процесів і наскільки глибоким змінам піддасться існуюча структура організації підприємства. Деталізація бізнес-процесів дозволяє виявити недоліки організації навіть там, де на функціональність перший погляд здається очевидною. Ознаками недосконалою діяльності можуть бути непотрібні, що не-керовані і дублюються роботи, неефективний документообіг (потрібного документа не надається в потрібному місці в потрібний час), відсутність зворотних зв'язків з управління (проведення роботи не залежить від результату) і по входу (об'єкти або інформація використовуються нераціонально) і т.д.
Знайдені в моделі AS-IS недоліки можна виправити при створенні моделі ТО-ВЕ ( «як буде») - моделі нової організації бізнес-процесів. Модель ТО-ВЕ потрібна для оцінки наслідків впровадження КІС та аналізу альтернативних, в тому числі кращих, шляхів виконання роботи і документування того, як підприємство буде функціонувати в майбутньому. Як правило, будується кілька моделей ТО-ВЕ, з яких по якомусь критерію вибирається найкраща. Наприклад, кожна з моделей ТО-ВЕ може відповідати певній ІС.
Проблема полягає в тому, що таких критеріїв може бути багато і непросто виділити найважливіший. Для того, щоб визначити ефективність бізнес-процесів після впровадження КІС, необхідна система метрики, тобто якість слід оцінювати кількісно.
BPwin надає аналітику два інструменти для оцінки моделі підприємства - вартісний аналіз, заснований на роботах (Activity Based Costing (визначення вартості на основі діяльності), АВС), і властивості, що визначаються користувачем (User Defined Properties, UDP). АВС є широко поширеною методикою, яка використовується міжнародними корпораціями та державними організаціями для ідентифікації рушіїв витрат в організації. Вартісний аналіз являє собою угоду про облік, що використовується для збору витрат, пов'язаних з роботами, з метою визначити загальну вартість процесу. АВС заснований на моделі робіт, оскільки кількісна оцінка неможлива без детального розуміння функціональності підприємства. Зазвичай АВС застосовується для того, щоб зрозуміти, як складаються вихідні витрати, і полегшити вибір потрібної моделі робіт при реорганізації діяльності підприємства (Business Process Reengineering (реінжиніринг бізнес-процесів), BPR). За допомогою вартісного аналізу можна визначити дійсну вартість виробництва продукту і підтримки клієнта, ідентифікувати найвитратніші роботи (ті, які повинні бути поліпшені в першу чергу) і т.д. в кожній з моделей AS-IS і ТО-ВЕ. Отже, вартісний аналіз дозволяє оцінити наслідки впровадження КІС і з'ясувати, приведе інформаційна система до підвищення продуктивності і економічного ефекту і до якого саме.
АВС може проводитися тільки тоді, коли модель роботи є послідовною (слід синтаксичним правилам IDEF0), коректною (відображає бізнес-процес), повної (охоплює всю розглянуту область) і стабільної (проходить цикл експертизи без змін). Ця методика включає в себе такі поняття, як об'єкт витрат (причина, по якій робота виконується, зазвичай це - основний вихід роботи, вартість робіт є вартість об'єктів витрат), рушій витрат (характеристики входів та управлінь роботи, які впливають на те, як виконується і як довго триває робота) і центри витрат (центри витрат можна трактувати як статті витрат).
При проведенні вартісного аналізу в BPwin спочатку задаються одиниці виміру часу і грошей, так-леї описуються центри витрат (cost centers) і потім для кожної роботи на діаграмі декомпозиції призначаються тривалість (duration), частота проведення даної роботи в рамках загального процесу (frequency) і суми по кожному центру витрат, тобто задається вартість кожної роботи по кожній статті витрат. Витрати вищестоящої роботи визначаються як сума витрат дочірніх робіт по кожному центру витрат. Такий досить спрощений принцип підрахунку справедливий в разі, якщо роботи виконуються послідовно. Якщо ж схема виконання більш складна, можна відмовитися від підрахунку і задати підсумкові суми вручну або скористатися спеціалізованим засобом вартісного аналізу EasyABC. Результати вартісного аналізу наочно представляються на спеціальному звіті BPwin - Activity Cost Report (звіт про вартість активності) (ACR). AВС дозволяє оцінити вартісні і тимчасові характеристики системи. Якщо вартісних показників недостатньо, є можливість внесення власних метрик - властивостей, визначених користувачем (UDP). Кожній роботі можна поставити у відповідність набір UDP і проаналізувати результат в спеціальному звіті Diagram Object Report (звіт про об'єкт діаграми).